The development cycle of a semiconductor device generally includes a design phase, a fabrication phase, an assembly phase, and a test phase. During the design phase, the functionality of a device is specified, and circuitry for implementing the functionality is laid out and optimized (i.e., a device design is developed). Typically, operation of the circuitry is simulated by a computer, or a physical prototype is constructed, and then the simulated or physical circuitry is tested to determine if it functions as expected. If it does not, the circuitry may be further optimized or redesigned.
During the fabrication phase, the device design is used to construct physical semiconductor devices. Typically, this involves the construction of devices in a production environment. However, the construction of device prototypes in an engineering context is also sometimes considered part of the fabrication phase.
During the assembly phase, semiconductor devices are packaged in various ways. Devices may also be stacked, or otherwise coupled, to form three-dimensional semiconductor devices.
During the test phase, semiconductor devices are tested using one or more test programs, to ensure that the devices function as designed. In some cases, testing may include “go/no go” testing, where devices are evaluated as “good” or “not good”. In other cases, and by way of example, testing may be used to separate devices into different performance classes, or to identify failed devices that may be repairable.
Although the development cycle of a semiconductor device typically commences with a design phase and ends with a test phase, the various phases can be performed in parallel or in various orders. For example, the test phase may begin soon after (or in parallel with) the design phase; and simulated, prototype or production devices may be tested during any or all of the design phase, the fabrication phase and the assembly phase. Also, for example, data obtained during the test phase (e.g., functional test data, structural test data, or yield data) may be used in any or all of the design, fabrication or assembly phases to refine or improve a device design, or to identify adjustments in the fabrication or assembly phases that will improve yield. Data obtained during the test phase may also be used to improve, or to adjust (e.g., rewrite or adjust the limits of), the test program itself.
In some cases, a semiconductor device's entire development cycle is provided and managed by an integrated device manufacturer (IDM). However, over the past few decades, it has become more and more common for the phases of a semiconductor device's development cycle to be distributed amongst various parties. For example, a device design and its test program may be developed by a semiconductor design company, such as a fabless semiconductor company. The fabless semiconductor company may then provide the device design and the test program to a wafer foundry or outsourced semiconductor assembly and test (OSAT) facility for the fabrication, assembly and test of semiconductor devices in accord with the design.
A distributed development cycle can provide various advantages, such as specialization, reduction of cost, and sharing of risk. However, a distributed development cycle can also introduce some complications. For example, a semiconductor design company may prefer to use a particular hardware or software platform for designing a device and developing its test program, but a foundry or OSAT facility may prefer to use a different hardware or software platform for executing test programs. Frequently, this requires one or both of the design company and the foundry/OSAT facility to make accommodations for the other. On the design company side, this may require a change in the hardware or software it uses to develop a test program, and sometimes even a change in the hardware or software it uses to design a device. On the foundry or OSAT facility side, differences in the platforms used by it and a design company may require the foundry or OSAT facility to install or configure a new hardware or software platform for executing the design company's test program.
There are other complications that arise with a distributed development cycle. For example, a single semiconductor design company may find it difficult to contract with different foundries and OSAT facilities, because different fabrication, assembly and test vendors may use different hardware or software platforms, and working with these diverse vendors may require the design company to spend significant time reworking its test programs for different hardware or software platforms. Often, this is just not feasible. Similarly, a fabrication, assembly or test vendor may find it difficult to work with some semiconductor design companies, because the design companies provide test programs that are designed for different hardware or software platforms, and the accommodations that the foundry or OSAT facility needs to make to work with different hardware or software platforms are too expensive to absorb (and not feasible to pass on to customers).
Still other complications posed by a distributed development cycle relate to the flow of data between a development cycle's participants. For example, a design company that provides an OSAT facility with electronic information on its device design (including a device test program) will not want this information to be shared with its competitors, which competitors might also be using the services of the OSAT facility. Nor will the design company want the results of its device tests, device yield data, or other proprietary data shared with its competitors. In some cases, the design company might even want to keep this information from the OSAT facility itself. Similarly, the OSAT facility might want to keep certain information about its test floor from its customers.
In some cases, the above noted complications lead to participants in a distributed development cycle being selective about the parties with whom they contract. In other cases, one or both of the parties to a contract will agree to accommodate the platform requirements of the other. However, such accommodations can be costly—both monetarily, and in the form of time delays. One reason for the cost is that semiconductor test software typically uses a complex stack, which stack reaches from embedded software, to low level drivers, to a high level graphical user interface (GUI) and test system controller operating system (OS). Different test programs (e.g., test programs from different design companies, or test programs for different devices) may require, or expect, different software, different operating systems (e.g., RedHat's Linux® or Microsoft's Windows®), and different versions of same. Different test programs may also require or expect deployment on particular types, models or configurations of computer systems (e.g., different workstations). Different test programs may also require, or expect, different environmental settings, code libraries and production integration tools. As a result, a fabrication, assembly or test vendor that is willing to make accommodations may need to install and configure new software, and in some cases may even need to install and configure a new computer system or operating system. This can lead to significant overhead expense, downtime and delay for both a semiconductor design company and its fabrication, assembly and test vendors.
Some of the above-noted complications can also be experienced by an IDM that operates a test floor shared by different product lines.
It is noted that, in the following description, like reference numbers appearing in different drawing figures refer to like elements/features. Often, therefore, like elements/features that appear in different drawing figures will not be described in detail with respect to each of the drawing figures.